[update] AWS Elemental MediaLiveがbandwidth reduction filterをサポートしました！

はじめに

清水です。ブロードキャストグレードのライブ動画処理サービスであるAWS Elemental MediaLiveでbandwidth reduction filterがサポートされました。AVCならびにHEVCエンコードで利用可能です。2024/09/23付けでWhat's New at AWSにポストがありました。

• AWS Elemental MediaLive introduces bandwidth reduction filter - AWS

帯域幅削減フィルター などと日本語では呼ばれる bandwidth reduction filter 、MediaLiveに先行して昨年2023年6月にAWS Elemental MediaConvertでサポートされていました。

• [update] AWS Elemental MediaConvertでbandwidth reduction filterが利用可能になりました！ | DevelopersIO

知覚できない信号や、カメラセンサーを通して混入してしまうランダムなノイズ（temporal noise）を減らし、動画コンテンツの品質に影響を与えるとなくビットレートの削減が可能であるbandwidth reduction filter、What's New at AWSのポストによるとビデオのエンコード効率を平均7%向上させることができるとのことです。

実際にMediaConvertのbandwidth reduction filterを検証した例では、スマホで撮影した動画の変換で品質に影響を与えることなく最大8%のビットレート削減が確認できました。そんな帯域幅の削減、またストレージ容量の削減などへの効果が期待できるbandwidth reduction filterがMediaLiveにやってきました！

本エントリではこのMediaLiveのbandwidth reduction filterを実際に使用してみたのでまとめてみたいと思います。MediaConvertのbandwidth reduction filterを検証した際に最も帯域削減の効果が表れた動画コンテンツに対し、MediaLiveでもbandwidth reduction filterを適用したところ、動画品質に影響を与えることなく10%の帯域削減が確認できました。

MediaLiveのbandwidth reduction filterを使ってみた

MediaLiveリソースの作成とbandwidth reduction filter設定項目の確認

それでは実際にMediaLiveでbandwidth reduction filterを使ってみましょう。MediaLiveの映像ソースとしては、MediaConvertのbandwidth reduction filterを検証した際に最も効果が大きかった「夜の吉祥寺駅南口」の動画を使用します。

筆者がiPhone XSで夜の吉祥寺駅前、南口の高架下を撮影したもので、フルHDの解像度の動画です。MediaConvertのbandwidth reduction filterを使った検証では、同等の動画品質を維持しつつ、ビットレートならびにファイル容量で8%強の削減効果がみられました。

この動画ファイルをMediaLiveの入力ソースとして使用します。MediaLiveのInput typeでMP4を選択するかたちですが、もともとの動画ファイルはiPhone XSで撮影したMOV形式です。これをMediaConvertのSystem Preset System-Generic_Hd_Mp4_Avc_Aac_16x9_Sdr_1920x1080p_30Hz_10Mbps_Qvbr_Vq9でMP4形式に変換しておきます。（具体的にはこちらのブログエントリで比較に使用した、bandwidth reduction filterを有効にしていない状態で変換したファイルを使用しました。）

MediaLiveのChannelリソースや、視聴確認のためのMediaPackageなどの環境はMediaLive Workflow wizardで作成します。InputとしてMP4を選択して、Input sourceに先ほどの動画ファイルのS3 URLを入力します。またOutputとしてMediaPackageを選択、Video renditionとしては1080p30のみを選択しました。以下が「Step 4 Review and create resources」の画面です。

MediaLive workflowが作成できたら、このworkflowのchannel詳細画面に進みEdit channelを行います。Output groupsの「1. mediapackage (MediaPackage)」、「Output 1: emp_1080p30」の項目を確認します。まずはRate ControlのAdditional Settingsの項目、Max Bitrateをworkflow作成時のデフォルト5000000から10000000に変更しました。

続いて、今回のアップデート内容であるBandwidth reducition filter関連の設定です。Videoの Additional Encoding Settings の項目を展開します。

まずはQuality Levelの項目でENHANCED_QUALITYを選択します。

このQuality Levelの項目はBandwidth reduction filterと直接の関係はありませんが、Don't IncludeもしくはSTANDARD_QUALITYのままBandwidth reduction filterを有効にしようとすると、以下のようにValidation Errorとなってしまいたした。そのため、本エントリではENHANCED_QUALITYを選択して進めます。（なお、コーデックとしてH.265/HEVCを選択した場合はこのQuality Levelの項目は現れませんでした。H.264/AVCの場合のみ、Quality Level: ENHANCED_QUALITYの選択が必要と理解しています。）

続いてFilter Settingsの項目でBandwidth reduction filterを選択します。Filter StrengthとPost-Filter Sharpening、2つの設定項目が現れますので必要に応じてこれらを設定します。今回はどちらもデフォルト値のFilter Strength: AUTO、Post-Filter Sharpening: DISABLEDで検証を行いました。この設定を本エントリ中では brf有効 と称します。

比較対象となる brf無効 については、Quality Level: ENHANCED QUALITYのみを指定し、Filter SettingsはDon't Include（空欄）とした設定としました。（あくまでBandwidth reduction filterの有無での帯域削減などの効果を確認したいため、このような比較としています。）

bandwidth reduction filterの効果を確認

実際にMediaLiveを使いで映像ソースをエンコード、bandwidth reduction filterの効果を確認していきます。まずはbrf無効の状態でChannelをStartさせ、10分ちょっとの間running状態とします。続いてChannelを一旦停止、同じChannelにてbrf有効の状態に設定してからChannelを再開します。同様に10分ちょっとrunning状態として、その間のデータ出力についてのCloudWatchメトリクスを確認する、という比較を行いました。

またbandwidth reduction filterの無効、有効の状態それぞれで、MediaPackage経由の映像視聴についても行いました。こちらは動画コンテンツの品質の確認が目的でしたが、bandwidth reduction filterの有無で区別はできない、つまり品質は同等といえるものでした。

以下、MediaLiveのCloudWatchメトリクスについての確認です。MediaLiveのChannel詳細画面でHealthの項目のMetrics、Network in (Mbps)を確認します。

拡大ボタン（両向き矢印が「X」のようにクロスしているところ）を押下して、グラフを拡大してみます。グラフ横軸の、おおよそ08:00から08:10が brf無効 の状態、08:20-08:30が brf有効 の状態のメトリクスになります。ぱっとみたところ、ある程度の帯域削減ができていそうですよね。

該当期間のNewtwork outの値は、1分間ではなく5分間の平均を確認しました。以下はbrf無効の08:00のタイミングでの5分間の平均メトリクス、 7.48 Mbps という値でした。（小数点以下第3位を四捨五入、以下同様です。）

brf有効の08:20のタイミングです。こちらは5分間の平均メトリクスで 6.72 Mbpsという値でした。

MediaPackageのMetricsについても確認してみましょう。MediaPackageのChannel詳細画面でMetricsの項目のChannel operational metrics、Ingress Bytes: Sumを確認します。

拡大すると以下のようなグラフでした。こちらもグラフ横軸の、おおよそ08:00から08:10が brf無効 の状態、08:20-08:30が brf有効 の状態のメトリクスになります。

該当期間のIngress bytesの値を1分間から5分間に変更して、合計値を確認します。brf無効の08:00のタイミングでは合計 264,071,667 Bytes でした。

brf有効の08:20のタイミングでは、236,632,355 BytesというIngress bytes合計値となりました。

これらMediaLiveのNetwork out 平均値 (Mbps)とMediaPackageのIngress Bytes 合計値 (Byte)、それぞれをbrf無効/brf有効とで比較してみたのが以下の表です。削減率として(1-(brf有効の際の値/brf無効の際の値))*100で計算した値もまとめています。両方のメトリクスで10%強の帯域削減の効果が確認できますね！

	brf無効	brf有効	削減率
MediaLive Network out 平均値 (Mbps)	7.48	6.72	10.16 %
MediaPackage Ingress Bytes 合計値 (Byte)	264,071,667	236,632,355	10.39 %

まとめ

AWS Elemental MediaLiveで新たに利用可能になったbandwidth reduction filterについて確認してみました。MediaConvertでサポートされた際にも効果を実感していたのですが、MediaLiveでも同様に効果が感じられましたね。画質を維持しながら帯域幅を削減することで、ライブ配信であれば特にデータ転送量の削減が期待できます。視聴者側としてはより少ないデータ量でこれまでと変わらない画質の映像が視聴できます。配信者側としても、CloudFrontなどCDNのデータ転送量が少なくなり利用コストの削減にもつながります。嬉しいことづくしですよね。

ただし、今回のブログエントリでの検証は効果が比較的表れやすい映像を意図的に選んだ結果となります。（MediaConvertでの検証であらかじめ効果が大きかった映像コンテンツを検証用に選んでいます。）実際にエンコードするコンテンツによって効果は変わります。MediaConvertでの検証の際にも効果が少なかった映像コンテンツはありました。What's New at AWSのポストで謳っている平均7%のエンコード効率の向上をベースにしつつ、実際のユースケースでどの程度の削減になるかを確認して導入の判断材料にしましょう。また、2つのパラメータ、Filter StrengthとPost-Filter Sharpeningの設定と、その効果を実際の映像で確認することもポイントなるかと思います。上手に活用していきましょう。